perm filename CH1.BH[ESS,JMC] blob
sn#061885 filedate 1973-09-09 generic text, type T, neo UTF8
COMMENT ⊗ VALID 00002 PAGES
RECORD PAGE DESCRIPTION
00001 00001
00002 00002 INTRODUCTION TO TIMESHARING
00007 ENDMK
⊗;
INTRODUCTION TO TIMESHARING
This manual describes the use of the timesharing system at
the Stanford Artificial Intelligence Laboratory. The first section is
a brief, general explanation of timesharing, to make the detailed
explanations which follow fit into a coherent pattern.
On a batch computer system, the processing of a programming
problem is something like this: You write a program and prepare it
for input by punching it on cards. Control cards, which identify you
and specify what you want done, are added to the program cards.
This program deck is brought to the computer center. Some time
later, you pick up a listing and your original input deck. You edit
the program, if it is wrong, by punching new cards to replace the
wrong ones. You repeat this cycle until the program works.
This description leaves out the details of what the computer does.
Programs are usually processed by a compiler, which translates
programs into machine language. The linking loader takes the
compiler output and loads it into the computer's main memory, and
links your program to any subroutines that it requires. Finally,
the loaded program is run by the computer.
With timesharing, you go through the same steps, but instead of
having a line of jobs waiting to use the computer, many jobs can be
run at once. The computer gives short bursts of attention to each.
Because of this, you can type in your program at a computer terminal
(basically a typewriter) in your office. Instead of cards, the program
is stored in the computer's file system; program editing is done with
the computer as well as program execution. You can go through the
edit-compile-debug cycle much more quickly than in a batch system.
Also, since you are communicating with the computer while it is
running your program, you can debug "interactively," which means that
you can stop the program at any point and see what it's doing.
All of this is made possible by the timesharing monitor, a
pogram which keeps track of all the jobs on the system. You communicate
with the monitor in two ways: by commands typed at your terminal, and
by special instructions in your program which make requests to the monitor.
These instructions are used because your job uses resources, like core
storage and input/output devices, which must be allocated among the jobs
by the monitor. Also, the monitor does many things
for you as a sort of subroutine of your program. Chapter 2 of the
monitor manual describes these special monitor calls, known as UUOs.
This chapter describes the commands you type at your terminal.
The system tries to make writing programs as simple as if each
user had his own computer. For example, is seems to each user as if his
program were loaded into a complete core storage starting from address
zero, although the computer's core really contains many users at once.
Special "relocation" hardware translates addresses in each
program to the area in core where that program really is.
A program's "core image" or "address space" is the
simulated core addresses the program uses.